1. Field of the Invention
The present invention relates generally to computer databases and more particularly to a system and method for routing database requests from application logic to a cache and a database.
2. Discussion of the Related Art
Many computer applications today utilize a database to store, retrieve, and manipulate information. Simply put, a database refers to a collection of information organized in such a way that a computer program can quickly select desired pieces of data. For example, an individual might use a database to store contact information from their rolodex, such as names, addresses, and phone numbers, whereas a business entity might store information tracking inventory or customer orders.
Databases include the hardware that physically stores the data, and the software that utilizes the hardware""s file system to store the data and provide a standardized method for retrieving or changing the data. A database management system (DBMS) provides access to information in a database. This is a collection of programs that enables a user to enter, organize, and select data in a database. The DBMS accepts requests for data (referred to herein as database requests) from an application program and instructs the operating system to transfer the appropriate data. Database requests can include, for example, read-only requests for database information (referred to herein as informational database requests) and requests to modify database information (referred to herein as transactional database requests). With respect to hardware, database machines are often specially designed computers that store the actual databases and run the DBMS and related software.
FIG. 3A depicts a conventional database configuration 300A, wherein a computer application 102 accesses information stored in a database 104 having a DBMS 120. Application 102 includes application logic 110 and a database driver 114. Application 102 and database 104 interact in a client/server relationship, where application 102 is the client and database 104 is the server. Application logic 110 establishes a connection 310 to DBMS 120 using database driver 114. Database driver 114 provides an Application Programming Interface (API) that allows application logic 110 to communicate with database 104 using function calls included in the API. Conventional database drivers 114 typically handle communication between a client (e.g., application logic 110) and a single database server, or possibly between multiple servers of the same basic type. Many conventional database drivers 114 make use of a proprietary client/server communication protocol (shown as line 310 in FIG. 3A).
The performance of the conventional client/server database design depicted in FIG. 3A can be improved with the addition of a cache. FIG. 3B depicts a second conventional database configuration 300B wherein a cache 106 is inserted between application 102 and database 104. This configuration is referred to herein as an inline cache. Application logic 110 uses a cache driver 302 to establish a connection with cache 106. Cache 106 provides rapid access to a subset of the database information stored in database 104, as will be apparent to those skilled in the art. Cache 106 establishes a connection 314 with DBMS 120 using database driver 114, where the driver can be integrated within the cache.
All database requests from application logic 110 are routed first to cache 106. Cache 106 may handle requests differently depending on the type of operation requested and whether the target data is stored in cache 106. For example, informational database requests can be handled by cache 106 without going to database 104, so long as the information that is the target of the request (i.e., the target data) in stored in cache 106. Since the response time of cache 106 is significantly faster than that of database 104, performance is increased as the percentage of information database requests grows in relation to the total number of database requests.
Transactional database requests are performed in both cache 106 and database 104. Consistency between cache 106 and database 104 is maintained because transactional requests are performed on the database information stored in both locations. As a result, application logic 110 can only utilize those transactional requests that are understood by both cache 106 and database 104 for consistency to be maintained. For example, if application logic 110 issued a transactional request that was understood by database 104 but not by cache 106, the information would be changed in database 104 but not in cache 106, and the two would no longer be consistent. Therefore, only those requests for which database 104 and cache 106 share a common vocabulary are supported in this configuration.
Many database manufacturers provide for the execution of stored procedures within database 104 which can increase flexibility and performance. The implementation of these database-side capabilities may be proprietary to the database manufacturer. Third party manufacturers of inline caches may not have access to this proprietary information, and may therefore be unable to implement corresponding capabilities within the cache. As a result, consistency cannot be maintained between cache 106 and database 104 in inline cache configuration 300B if application logic 110 is allowed to utilize these database-side capabilities. This limitation forces software vendors to re-code their applications 102, eliminating any calls to database-side capabilities in favor of those operations within the vocabulary common to both cache and database.
Also, while the addition of the inline cache results in some performance improvement for the processing of informational requests, performance can degrade for the processing of transactional requests. The client generating the request must wait until the inline cache commits the changes to both the cache and the database. Adding the inline cache can therefore increase the amount of time the client must wait when processing transactional requests as compared to a database configuration without a cache (300A). Further, the requirement that the inline cache be inserted between the client and server and receive all database requests limits the flexibility of the inline configuration. For example, some application logic 110 cannot easily be modified to allow for the insertion of the inline cache.
Finally, the fault tolerance of the inline cache configuration depends upon the fault tolerance of the inline cache. Failure of the inline cache will result in database 104 being cut off from its clients, since all client request must pass through the failed cache 106.
What is needed is an improved system and method for routing database requests from application logic to a cache and a database that is both flexible and fault-tolerant, wherein transactional requests are handled efficiently and the application logic is able to take advantage of proprietary database mechanisms and/or database-side execution capabilities.
The present invention provides a system and method for routing database requests from application logic to a cache and a database, including receiving a database request from the application logic, determining whether the request is informational or transactional, routing the request to the cache if the database request is informational, and routing the request to the database if the request is transactional.
A first example embodiment of the present invention includes a database which is accessed using a first driver, a cache, and a second driver which determines whether database requests received from application logic are informational or transactional, where informational requests are routed to the cache and transactional requests are routed to the database using the first driver.
An advantage of the present invention is that transactional requests are routed to the database without passing through the cache, thereby enabling the application logic to utilize whatever proprietary database mechanisms and/or database-side execution capabilities are provided the database. Routing transactional requests to the database without passing through the cache also decreases the amount of time the client must remain locked pending completion of the transactional request.
Another advantage of the present invention is that informational requests are routed to, and handled by, the cache. As a result, those informational requests that can be handled by the cache need never be forwarded on to the database. The database, freed of the responsibility of handling these informational requests, may more efficiently handle those other requests that are routed to the database.
Another advantage of the present invention is that the fault-tolerance of the system does not depend upon the fault-tolerance of the cache. If the cache fails, all requests may be routed directly to the database until the cache is again operational. In other words, according to the present invention, the cache is not a system point of failure.
The present invention provides for the efficient processing of database requests, particularly where the requesting application issues informational requests in disproportion to the number of transactional requests. For example, applications which maintain a web site receive many more request for data than requests to change data. As a result, these applications will issue many more informational requests (that are not sensitive to cache consistency) than transactional requests to a backend database. The present invention is particularly well suited to processing database requests in this type of environment.